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(54) IVIethod and apparatus for increasing the security of wireless data services 



(57) The security of wireless communications be- 
tween two or more devices is enhanced by requiring de- 
tection of the physical proximity of the devices. One or 
more of the devices operates In a non-secure mode, 
wherein the authentication process required to enter in- 
to secure communications is disabled. Upon detection 
of the physical proximity of another device, the device 
enters a secure mode, wherein authentication Is ena- 
bled. The entry of a security code required by the au- 
thentication process may comprise the transmission of 
a device address or other data, either across the prox- 
imity detection interface or via the wireless communica- 
tions Interface. In addition to the detection of physical 
proximity, a hardware handshake protocol between the 
two devices may be defined. For additional security, the 
device must enter a handshake mode before the hard- 
ware handshake will complete. The handshake mode 
may require entry of a password or screening by a bio- 
metric sensor. Preferrably, the wireless communication 
system is based on the Bluetooth technology. 
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Description 

BACKGROUND OF THE INVENTION 

[0001 ] The present Invention relates generally to the 
field of wireless networks, and specifically to a method 
and apparatus of increased security in establishing ad 
hoc wireless piconets. 

[0002] Advances In microelectronics and packaging 
technology have prompted the development of a pleth- 
ora of electronic devices, such as, for example, laptop 
and desktop computers, personal digital assistants 
(PDA), mobile radlocommunication temnlnals, and the 
like. Traditionaiiy, such electronic devices have been 
connected to each other and to their various peripherals 
(such as printers, scanners, digital cameras, and the 
like) via wires or cables. Recent advances in radiocom- 
munications technology have led to the development of 
wireless network systems, wherein a wide variety of 
electronic devices may communicate wireiessly, La, 
without the need for physical Intenconnection via cables. 
Examples of such wireless network technology Include 
the IEEE 802.11 wireless Wide Area Network (WAN) 
standard and the Bluetooth® standard developed and 
promulgated by Telefonaktlebolaget LM. Ericsson. 
Sweden. 

[0003] The Bluetooth® technology allows the dynam- 
ic fonnation of ad hoc networks connecting electronic 
devices. Extensive deployment of the Bluetooth® tech- 
nology will lead to ubiquitous connectivity, wherein es- 
sentially all electronic devices will be able to communi- 
cate with each other. To facilitate this level of Intercon- 
nectlvlty, the Bluetooth® standard defines the connec- 
tivity protocols of devices Into small networks called pi- 
conets at the device link layer. In other words, the bulk 
of the tasks of dynamically establishing piconets, vali- 
dating the piconefs members, data communications be- 
tween members of the piconet, and the dissolution of 
the piconet, are transparent to the user. 
[0004] While this architecture promotes ease of use 
and, thus, facilitates its widespread acceptance, there 
exist situations In which more extensive user control Is 
desirable. In many cases, users may wish to explicitly 
define the parameters of a given piconet, including 
which devices are connected, and the circumstances at- 
tendant to the creation and dissolution of the piconet. 
Bluetooth® security protocols allow this degree of user 
control by having the user enter a specific code into each 
of two devices that he wishes to include in a piconet at 
the time of initial connection. These codes are used to 
generate a common link key, which is subsequently 
used by the Bluetooth® security protocols to authenti- 
cate the devices to each other prior to establishing a 
piconet link between them, and may be additionally 
used in data encryption. 

[0005] However, it is envisioned that Bluetooth® tech- 
nology may be embedded in devices with no keypad or 
other Input means for entering such a code. Additionally, 



the physical punching-in of security codes in a variety 
of devices is time consuming and prone to error. 

SUMMARY OF THE INVENTION 

5 

[0006] The present Invention entails a method of se- 
curing wireless communications between at least two 
devices across a wireless communications link, by de* 
tecting the physical proximity of the devices. One of the 

10 devices operates In a non-secure mode, wherein the au- 
thentication process required to enter Into secure com- 
munications is disabled. Upon detection of the physical 
proximity of another device, the device enters a secure 
mode, wherein authentication is enabled. The entry of 

15 a security code required by the authentication process 
may comprise the transmission of a device address or 
other data, either across the proximity detection inter- 
face or via the wireless communications interface. In ad- 
dition to the detection of physical proximity, an optional 

20 hardware handshake protocol between the two devices 
may be defined. For additional security, a further option- 
al requirement may be that the device enters a hand- 
shake mode before the hardware handshake will com- 
plete. For still greater security, the handshake mode 

25 may optionally req uire entry of a password or screening 
by a blometric sensor. 

BRIEF DESCRIPTION OF DRAWINGS 

30 [0007] 

Figure 1 is a timing diagram depicting a simple hard- 
ware handshal<e protocol; 
Figure 2 is a flowchart depicting the proximity de- 
35 tection and authentication method according to the 
present Invention. 

DETAILED DESCRIPTION OF THE INVENTION 

40 [0008] The present invention is directed to increased 
user-controlled security of communications between 
two or more electronic devices over a wireless network 
medium. A notable example of such wireless netwoh< 
technology is the Bluetooth® standard published by Tel- 

-^5 efonaktlebolaget L.M. Ericsson of Sweden. The Blue- 
tooth® interface Is a universal radio interiace in the 2.45 
GHz frequency band that enables portable electronic 
devices to connect and communicate wireiessly via 
short-range, ad hoc networks. Persons interested in var- 

50 ious details regarding the Bluetooth® technology are re- 
ferred to the article entitled The Bluetooth® Radio Sys- 
tem" authored by Jaap Haartsen, which can be found in 
the IEEE Personal Communications, February, 2000, 
the disclosure of which Is incorporated herein by refer- 

S5 ence. Security features of the Bluetooth® standard are 
described In Chapter 8 of Bluetooth Demystified by 
Nathan J. Muller. the disclosure of which is also incor- 
porated herein by reference. While the present invention 
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is explicated herein with reference to the Bluetooth® 
standard, It is noted that the present invention Is not lim- 
ited to such use, but may be employed to Increase user 
convenience and data communications security in any 
wireless network system. 

[0009] The Bluetooth® air Interface is based on a Fre- 
quency Hopping (FH), Code Division Multiple Access 
(CDMA) scheme. One Bluetooth® device, designated 
the "master" controls the FIH channel. All other Blue- 
tooth® devices participating in wireless communication 
on that channel, or in the "piconet," are referred to as 
"slaves' Every Bluetooth® device is identified by a 
unique 48-bit "Bluetooth® device address." A Blue- 
tooth® master device must know the device address of 
a slave before a connection to it can be established. A 
master device obtains the device addresses of sur- 
rounding slave devices thorough a process known as 
an "inquiry." Upon issuance of an inquiry by a master 
device, ail proximate Bluetooth® devtees that are in dis- 
coverable mode will respond by transmitting their device 
addresses to the inquiring device. A Bluetooth® device 
In non-discoverable mode ignores inquiries and does 
not transmit its device address to any other device (and 
hence does not join any piconets). 
[0010] Having obtained a slave device's Bluetooth® 
device address (such as through an Inquiry), a master 
device establishes a connection to the slave device thor- 
ough a process known as "paging." A page is always 
directed towards one device, and contains the targeted 
device's Bluetooth® device address, if the slave device 
is in connectabie mode, it may respond to the page and 
a connection Is established. If the slave device is In non- 
connectable mode, It will ignore the page request. A 
Bluetootii® device may enter non-connectable mode af- 
ter having already established one or more connections. 
[001 1 ] If the security settings on the slave device war- 
rant, the slave may decline to connect immediately fol- 
lowing a page, but may Instead demand authentication 
of the master device. This process Involves a 1 28-bit 
common secret link key, a 128-bit challenge, and a 
32-blt response. The secret link key is derived from an 
up to 1 28-blt security code entered Into both devices by 
a user, referred to herein as the "security code." If the 
authentk^atlon Is successful, a connection is formed, 
and the link key is retained by both devices and used to 
encrypt the data portion of communication packets 
transferred between them. This authentication proce- 
dure Is known as "pairing." A slave may be in a pairable 
mode. In which the above-described authentication pro- 
cedure is initiated, or In non-pal rable mode, in which 
case the slave cannot enter Into a secure connection. 
[0012] The Bluetooth® standard defines three secu- 
rity modes. Security mode 1 refers to the absence of any 
security. Mode 1 allows devices to communicate freely 
on any Bluetooth® piconet that they detect. Mode 1 is 
useful for ubiquitous automatic data communications, 
such as for example, trading business card between 
PDAs, or transmitting advertising data to a cell phone 



as a user passes a retail shop or restaurant. 
[001 3] Security mode 2 provides service-level securi- 
ty. Mode 2 allows for versatile access and authorization 
protocols, allowing for example, parallel applications on 
5 a particular devk:e to operate under different security 
levels. 

[001 4] Security mode 3 refers to the link-level securi- 
ty, wherein Identification, authentication, and encryption 
are enforced at the hardware level at the time of con- 

10 nection setup, and are thus transparent to the user. 
Mode 3 may be employed, for example, in a home net- 
work, where all devices are known, and where no for- 
eign" devices are contemplated as sharing access to the 
wireless network. 

IS [0015] Security modes 1 and 3 are "default" modes, 
In that devices in modes 1 or 3 enforce the relevant se- 
curity protocols automatically, regardless of the user or 
application. Security mode 2 provides for greater flexi- 
bility, and requires intervention by an application, a user, 

20 or both to define and implement the desired level of se- 
curity for each network connection. To support and en- 
able a variety of security protocols, the Bluetooth® ar- 
chitecture defines a security manager. A security man- 
ager is an entity In the network protocol stack that Is re- 

25 sponsible for storing and retrieving security-related in- 
formation on sen/Ices and devices, responding to ac- 
cess requests, enforcing authentication and/or encryp- 
tion, and the like. However, no hardware related aspects 
of the security manager are specified by the Bluetooth® 

30 architecture, such as any specific device physical prox- 
imity, hardware handshake modes, or the like. 
[001 6] In complex devices with sophisticated user in- 
terfaces, such as, for example, laptop computers, 
PDA's, or desktop and mobile telephone tenminals, the 

35 security manager may contain and Implement an arb\- 
trarily complex and Intricate set of security protocols. For 
example, highly secure wireless connections may be 
established for specific limited purposes, and subse- 
quently disbanded. Implementation of such secure net- 

40 work connections would nornially occur by the user en- 
tering a security code of up to 1 28 bits In each device to 
be securely, wirelessly connected. A combination link 
key is derived from the security code. The security code 
Is discarded and the combination link key Is retained by 

^5 each device and used for authentication during pairing 
and for encryption during data communications. 
[001 7] However, entry of a security code may be prob- 
lematic In the case of devices with no user Interface or 
a limited functionality user Interface, such as for exam- 

so pie, Bluetooth®- enabled headsets, digital cameras, 
scanners, and the like. One possible solution regarding 
such devices is the use of the Bluetooth® device ad- 
dress as a security code, assuming that the Bluetooth® 
device address Is printed on the wireless device or oth- 

55 erwlse available to the user In human-readable fomnat, 
allowing the user to enter this code into a Bluetooth® 
device having a user interface Including a numeric or 
alphanumeric Input capability. However, the Bluetooth® 
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device address will not always be made available, and 
additionally the provision of the address Is itself a secu- 
rity risk, as It allows secure connections to be made by 
another In the legitimate user's absence. 
[001 8] Additionally, even If all devices have user input 
functionality, the security of connections between the 
devices may be compromised by an unauthorized user 
gaining physical access to one or more of the devices 
{e.g., at night or at other times when the authorized user 
is away) and improperly Joining the piconet. The unau- 
thorized user may then be able to later eavesdrop com- 
munications on the piconet if he is within range to re- 
ceive them. 

[001 9] The present invention exploits the user's phys- 
ical control over devices to establish a secure connec- 
tion on a wireless piconet, regardless of the provision of 
a user Interface on each device or access to the Blue- 
tooth® device address. Furthermore, the present inven- 
tion severely limits the possibility of eavesdroppers join- 
ing a secure wireless piconet, regardless of their knowl- 
edge of the device addresses, or even of the Bluetooth® 
security code, by enforcing simultaneous physteal prox- 
imity of the devices to establish at least an initial secure 
connection. In addition, the present Invention provides 
a scalable range of increasing security by optionally fur- 
ther requiring: a hardware handshake between the de- 
vices when their physical proximity is detected; a spe- 
cific handshake mode in which the hardware handshake 
is enabled; and a user discrimination action (such as, 
for example, entering a password or passing a biometric 
scan) required to place the device in handshake mode. 
[0020] According to the present invention, a device 
has two modes - non-secure mode In which authentica- 
tion (as, for example, via "pairing" per the Bluetooth® 
protocol) is disallowed, and a secure mode, in which au- 
thentication Is allowed. A device operating In non-se- 
cure mode enters Its secure mode only upon detection 
of the physical proximity of another wireless communi- 
cation device. Thus, authentication Is only enabled 
when the devices are physically proximate each other. 
As used herein, "physical proximity" means that both de- 
vices are within at least twelve Inches of each other; 
more advantageously within at least six inches of each 
other; still more advantageously within at least two inch- 
es of each other; and most advantageously the devices 
are physically touching. The detection of physical prox- 
imity between two or more devices may be Implemented 
in a wide variety of ways; some of the many possible 
technologies and methods of detecting physical proxim- 
ity are described herein, byway of example and without 
limitation. 

[0021] According to another aspect of the present in- 
vention, the security of communications between devic- 
es may be enhanced by requiring, In addition to the mere 
detection of physical proximity between devices, that 
the devices affirmatively acknowledge each others' de- 
tection by engaging in a hardware handshake. The con- 
cept of a hardware handshake is well known in the elec- 



trical and communications arts. As a simple example. 
Figure 1 depkits a handshake typical of control signals 
on a computer bus. Initially, a master device asserts a 
STROBE signal 1 0, In this example by changing the log- 
s }c state of the signal from a 0 to a 1 . The STROBE signal 
10 may be directly connected to only one slave device, 
oraltematlveiy, it may qualify an address on an associ- 
ated address bus, which two or more slave devices de- 
code and compare to their assigned address. The de- 
10 tails of the bus operation other than control signals are 
not relevant to the current discussion. Upon detecting 
the STROBE signal 10, the slave device optionally per- 
fonns a task (such as for example retrieving and sup- 
plying data) and asserts an ACKNOWLEDGE signal 20, 
IS In this example also by transittoning the signal from a 
logic 0 to a 1 . The master device detects this transition 
of the ACKNOWLEDGE signal 20, and in response 
thereto, deasserts the STROBE signal 10. The 
STROBE signal 10 Is not deasserted until the master 
devk;e detects the assertion of the ACKNOWLEDGE 
signal 20. Similarly, the slave devk:e maintains the AC- 
KNOWLEDGE signal 20 In an asserted state until it 
senses the deassertion of the STROBE signal 10. Fol- 
lowing the deassertion of the STROBE signal 10, the 
slave deasserts the ACKNOWLEDGE signal 20. In gen- 
eral, a handshake may comprise any of a wide variety 
of directed call/response Interactions. The master may, 
for example, transmit a particular digital code to a slave, 
receiving a particular code in return, perhaps derived 
from the master's code. The specific details of the im- 
plementation of a hardware handshake are not relevant 
to the present Invention. The requirement of a hardware 
handshake in addition to the mere detection of physical 
proximity of the two devices provides additional security 
by ensuring that the two particular devices to be joined 
In a piconet are the ones that are proximate each other. 
[0022] According to another aspect of the present in- 
vention, the security of communications between the 
devices may be further enhanced by defining a hand- 
shake mode in one or both devices, wherein the hard- 
ware handshake is only enabled when the device is 
placed in handshal<e mode. This feature reduces the 
probability of a surreptitious or malicious handshake, 
wherein an eavesdropping device Is brought within 
physical proximity with a device and engages in a prox- 
imity detection and hardware handshake (thus allowing 
authentication) without the user's knowledge. Hand- 
shake mode may be enabled, for example, by a actuat- 
ing a switch on the device, or under software control. 
[0023] According to yet another aspect of the present 
invention, communications security is enhanced still fur- 
ther by requiring that the user enter a password into a 
device before that devices enters handshake mode. Al- 
ternatively, and for even greater security, handshake 
mode may be entered only after successfully passing a 
biometric scan via a biometric sensor. A biometric sen- 
sor detects and uniquely identifies an Immutable, unique 
physical characteristic or property of a person, such as 
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for example, a fingerprint, voiceprint, or eye iris pattern, 
and compares this characteristic to previously stored 
representation of the characteristic. An example of a bi- 
ometric sensor is the FIU-700 Fingerprint Identification 
Unit available from Sony Corporation, described at 
www.world.sony.com/Eiectronlcs/puppy/index.html, the 
disclosure of which Is incorporated herein by reference. 
[0024] As an example of the security features of the 
present invention, consider a BluetoottK&'equipped 
desktop or mobile telephone tennlnai. Two or more us- 
ers may wish to simultaneously engage in one end of a 
telephone conversation. Forconvenlence, voice quality, 
security (to prevent audible eavesdropping of the other 
side of the conversation), and/or decorum, each user 
may choose to employ a Biuetooth®-equ]pped headset 
In lieu of placing the telephone temnlnal in speakerphone 
mode. According to the present invention, both head- 
sets and the telephone terminal would initially be in non- 
secure mode, and capable only of non-secure commu- 
nications. To engage In pairing and establish a secure 
piconet according to the Bluetooth® protocol, the devto- 
es would need to be placed in secure mode by bringing 
them Into close physical proximity. The physical proxim- 
ity may be enforced by, for example, providing connec- 
tor contacts on each headset, that must be physically 
touched to corresponding connector contacts on the tel- 
ephone tennlnai. Additionally, the headset may require 
completion of a hardware handshake protocol with the 
telephone tennlnai to enter secure mode. The hardware 
handshake may take place via the exchange of electri- 
cal signals across the connector contacts when the two 
devices are touching. To accomplish the hardware 
handshake, the telephone terminal may require that the 
user enter a password on the keypad to place it In hand- 
shake mode, and each headset may require that a mo- 
mentary switch on the headset be depressed to place it 
In handshake mode. 

[0025] The Bluetooth® device address of each head- 
set, or other data, may be transferred from each headset 
to the telephone terminal as part of the authentication 
process, either across the contact connectors Interface 
or via the Bluetooth® air Interface, and may be used as 
the security code to generate a combination link key be- 
tween the headset and the telephone terminal. This re- 
lieves the user of the task of manually entering a Blue- 
tooth® security code into the telephone temnlnal, and 
does not require that the Bluetooth® device address be 
printed on the body of the headset. 
[0026] Due to the dominion exercised by the user over 
the physical proximity of the telephone temilnal and 
each headset in establishing the communication link, 
and additionally due to the requirement that the devices 
be placed In a handshake mode prior to the exchange 
of security codes {and In particular requiring the entry of 
a password on one device to do so), an outsider with a 
Bluetooth®-enabled headset, even within range of the 
piconet, would be unable to eavesdrop the conversa- 
tion, as the data communications are encrypted by the 



common link key. The outsider may not surreptitiously 
join the piconet, as this would require not only physically 
touching his headset to the telephone terminal, but ad- 
ditionally entering the password into the telephone ter- 
5 minal. 

[0027] Figure 2 depicts, in flowchart fomi, the process 
of engaging a slave device, such as a headset, in a se- 
cure piconet according to an exemplary embodiment of 
the present invention. The device is initially in non-se- 

10 cure mode (step 1 00). To enable the device to Join a se- 
cure pteonet, the user enables a handshake mode on 
the device (step 11 0). This may comprise, for example, 
depressing a momentary switch on the device. A prox- 
imity detector in the device detennines if it is in suffi- 

is cientty close physical proximity with a master device 
(step 120). if not, the device may not perform authenti- 
cation and enter a secure piconet, but may enter into a 
non-secure piconet that does not require authentication 
(step 130). If the devtee detects physical proximity to 

20 another devtee, it completes a hardware handshake 
with the device across the proximity detection interface 
(step 140). If the devfee falls to complete the hardware 
handshake, it may only join a non-secure piconet (step 
130). When the handshake protocol is completed, the 

25 slave devtoe may transmit a security code to the master 
devtee for use In generating a link key (step 150). This 
transmission may be across the proximity interface, or 
alternatively may be across the wireless communk;ation 
air interface. The slave devk;e then challenges the mas- 

30 ter device to authentteate Itself, using the link key gen- 
erated from the security code (step 160). The two de- 
vices proceed with the authentteatlon procedure, and 
then fonn a secure piconet, with encrypted data com- 
munication (step 170). 

35 [0028] As in the above example, the Interface that de- 
tects and verifies the physical proximity of two or more 
devices, and that optionally engages In a hardware 
handshake between the devices, may additionally com- 
prise the medium for the transmission of a Bluetooth® 

40 security code between the devices (which may be the 
Bluetooth® device address of one device). In one illus- 
trative embodiment, this may comprise the provision of 
one or more electrical contacts, for example affixed to 
the external surface of each device, establishing elec- 

^5 trical contact and hence data communications with a 
similarly positioned electrical contact disposed on the 
exterior of another device. One example of a single con- 
nector contact capable of two-way data communica- 
tions is the IButton® technology available from Dallas 

50 Semiconductor, Inc., of Dallas, Texas, and described in 
"The Book of IButton® Standards," document 081297, 
published by Dallas Semiconductor, Inc., and incorpo- 
rated herein by reference. 

[0029] Altematlvely, the connector contacts on Blue- 
55 tooth®-enabled devices may comprise two or more ex- 
ternal contacts, as are currently provided on many mo- 
bile radiocommunicatlon terminals for connection to bat- 
tery rechargers and the like. The multiple connection 



9 



EP1239 630 A2 



10 



contacts may define transmit and receive signal tenmi- 
nals, as is well known in serial data communications 
systems. The connector contacts may be spatially ori- 
ented, as through the provision of physically mating 
housings, forcing a relative orientation between the two 
devices and hence a specific alignment and connection 
order. Such surface connection contacts and alignment 
enforcement issues are well known in the art, are not 
critical to the present Invention, and thus are not further 
explicated herein. As another example, the electrical 
connection between the two devices may be accom- 
plished across one or more electrically conductive ca- 
bles. 

[0030] In another exemplary embodiment, the physi- 
cal proximity detection and Bluetooth® security code 
transmission system may comprise an electromagnetic 
link between the devices to be connected, if the electro- 
magnetic link has a sufftoiently short operating range, 
the security advantages of requiring close physk:al prox- 
imity between the devices to establish a link are real- 
ized, but the need to actually touch the devices to each 
other in any particular orientation or configuration is 
avoided. Such an electromagnetic link may comprise in- 
ductive or capacitive coupling or magnetic coupling. 
[0031] One example of a well-developed technology 
suited for such application Is the field of radio frequency 
identification (RFID). An RFID system is typically asym- 
metrical, comprising a relatively complex RFID inten^o- 
gator (also known as an RFID reader), and a plurality of 
relatively simple corresponding RFID transponders or 
"tags." When one or more RFID tags come Into the op- 
erating range of an RFID interrogator, they transmit data 
(typically, a unique Identification code) to the Inten-oga- 
tor. This asymmetry of design may be well suited to 
Bluetooth® devices. For example, in the scenario de- 
scribed above, an RFID inten'ogator may be incorporat- 
ed Into the relatively complex telephone terminal, with 
the relatively simple headsets equipped with con-e- 
sponding RFID tag circuitry. In this scenario, the tele- 
phone tenninai would function as a "master, "with each 
headset functioning as a "slave." This master/slave 
functional designation may, or may not, con-espond to 
the master/slave functional designation defined by the 
Bluetooth® specification regarding the establishment of 
piconets. The RFID Inten-ogator may output a single fre- 
quency RF signal with a limited effective range, with 
each RFID tag, via a response signal, responding by 
communicating an identification code. The RFID inter- 
rogator may generate an RF sine wave that optionally 
provides power to the RFID tags, a synchronized clock 
source to the RFID tags, and functions as a carrier for 
returned data from RFID tags. Each RFID tag in a Blue- 
tooth® device may contain a coii antenna. The time-var- 
ying magnetic field of the electro-magnetic output of 
RFID interrogator Induces an AC voltage In the coii an- 
tenna of the RFID tag as the slave Bluetooth® device is 
brought within range of the RFID interrogator. This volt- 
age may be rectified by electronics in the RFID tag, and 



power a sllteon memory chip and associated logic. Al- 
ternatively, the RFiD tag may be powered by a separate 
power source, such as a battery. Once the RFiD tag has 
received sufficient energy from Its coll antenna or bat- 

5 tery to operate correctly, it divides down the RF earner 
signal and begins clocking its data to an output transistor 
connected across the coil antenna. The output transistor 
shunts the coil sequentialiy, corresponding to the data 
being clocked out of the memory array. Shunting the coil 

10 causes a momentary fluctuation of the carrier signal, 
which is detected by the RFID interrogator in the master 
Bluetooth® device. In this manner, commonly referred 
to as 'backscatter modulation," each slave Bluetooth® 
devtee may communicate its Bluetooth® security code 

15 or other data to the master Bluetooth® devtee. Both pas- 
sive (unpowered tags) and active (powered tags) RFID 
systems are well known In the art. For further explana- 
tion, one is directed "Micro ID 125 kHz RFID System 
Design Guide," publication no. DS51f15E, available 

20 from Microchip Inc. , of Chandler, Arizona, the discbsure 
of which is Incorporated herein by reference. 
[0032] in another exemplary embodiment, the prox- 
imity detection and security code transmission system 
of the present Invention may comprise magnetic cou- 

25 piing technology. Magnetic coupling technologies are 
employed in Electromagnetic Article Surveillance (EAS) 
systems commonly used for anti-theft control of books 
in libraries, CDs in stores, and the like. In such EAS sys- 
tems, an altemating magnetic field Is applied within an 

30 Interrogation zone and the presence of a ferromagnetic 
marker within the zone is detected based on signals pro- 
duced by the marker in response to the applied field. As 
the magnetic field alternates, the magnetization of the 
marker material reverses. Each magnetization reversal 

35 produces a pulse of an external polar magnetic field, 
which can be detected. Incorporation of this technology 
is directly analogous to that of the RFID system de- 
scribed above, with the master Bluetooth® device con- 
taining a magnetic inten-ogator and the master Blue- 

^0 tooth® devices containing a ferromagnette mari<er. 
Magnetic coupled mari<ers are described In U.S. Patent 
No. 3,665.449 to Elder et a/., entitled "Method and Ap- 
paratus for the Detecting at a Distance the Status and 
Identity of Objects," the disclosure of which is incorpo- 

^5 rated herein by reference. As an example, a magnetic 
strip and detection system utilizing this technology is 
commercially available from 3M of St. Paul, Minn., and 
Is sold under the product name TATTLE TAPE®. 
[0033] In yet another exemplary embodiment of the 

50 present Invention, the detection of the physical proximity 
of two or more Bluetooth® devices to each other, and 
the exchange of a security code between the devices, 
may be accomplished with a llne-of-slght transmission 
and concomitant reception, such as an infrared or other 

55 optical data link. As one example of such technology, 
the Infrared Data Association (IrDA), an Industry con- 
sortium, has published both IriDA Data and IrDA Control 
specifications. IrDA Data is an interoperable universal 
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two way cordless infrared light transmission data port 
capable of up to 4Mb/8 data transfer across as little as 
a 20 cm (defined for low power devices). IrOA Control 
is an infrared communication standard that allows cord- 
less peripherals to Interact with many types of intelligent 
host devices at data rates up to 75Kb/8. Further infor- 
mation Is available from the "IrDA SIR Data Specifica- 
tion " "irDA Control Specification," and "IrCOMM 1 .0," 
published by the Infrared Data Association of Walnut 
Creek, California (www.irda.org), and Incorporated 
herein by reference. The optical interface may work via 
llne-of-slght transmission through the air, or altemative- 
ly via one or more optkial waveguides, such as for ex- 
ample, fiber optics cable. 

[0034] in still another exemplary embodiment of the 
present invention, the physical proximity detection and 
security code exchange interface may comprise a limit- 
ed-range ultrasonic, audible, or other sonic system. In 
such a system, the proximity of the devices may be de- 
tected by measuring the signal propagation time be- 
tween the two devices. 

[0035] According to the present invention, the security 
of dynamically created ad-hoc wireless networking pi- 
conets is enhanced by exploiting the user's physical do- 
minion over the devices to be connected, by requiring 
that the devices be brought Into close physical proximity 
to each other and additionally by engaging in a hardware 
handshake. Once proximity is detected and the hand- 
shake is complete, the devtees may engage in authen- 
tication procedures, such as the "pairing" procedure de- 
fined in the Bluetooth® specification, to establish secure 
piconet connections. It Is not necessary for the present 
invention that a Bluetooth® security code {e.g., the 
Bluetooth® device address of one or more of the devte- 
es) be transferred across the same data link as that used 
to verify physical proximity and complete the handshake 
protocol. A security code may be transferred across the 
wireless networking air Interface, but according to the 
present Invention, completion of the authentication pro- 
cedure depends upon the detection of proximity and op- 
tionally the completion of the hardware handshake. In 
this manner, the proximity detection and handshake 
hardware of the present Invention is minimized In scope 
and complexity, with concomitant resulting cost savings. 
[0036] All of the proximity detection and data commu- 
nication technologies described above are applicable to 
an embodiment of the present Invention wherein only 
proximity detection, and optionally hardware handshak- 
ing, occur across the proximity detection Interface, and 
the exchange of security codes occurs across the wire- 
less network air Interface. For example, a simple elec- 
trical contact between one or more externally located 
connection contacts on each devtee may be sufficient 
for proximity detection and hardware handshake. Alter- 
natively, electromagnette coupling (Including Inductive 
and capacltive coupling and magnetic coupling) may be 
detected, thus verifying that the devices are within a lim- 
ited operating range, without the transmission of data 



oocuning across the Interface. Additionally, an infrared 
or other optical line-of-sight interface, or a short-range 
ultrasonic, acoustic, or other sonic interface may be uti- 
lized, in general, those of ordinary skill In the art will reo- 

s ognize that a wide array of technologies and techniques 
may be employed to verify the physical proximity of two 
or more devices and complete a hardware handshake, 
to enable the establishment of secure conrvnunicattons 
as disclosed and claimed herein. 

10 [0037] Thus, although the present invention has been 
described herein with respect to particular features, as- 
pects and embodiments thereof, it will be apparent that 
numerous variations, modifications, and otiier embodi- 
ments are possible within the broad scope of the present 

IS invention, and accordingly, all variations, modifications 
and embodiments are to be regarded as being within 
the scope of the invention. The present embodiments 
are therefore to be construed in all aspects as illustrative 
and not restrfc:tive and ail changes coming within the 

20 meaning and equivalency range of the appended claims 
are intended to be embraced therein. 



Claims 

25 

1 . A method of securing wireless communications be- 
tween two devices across a wireless communica- 
tions link, comprising: 

30 detecting the physical proximity of said devices; 

pertonning authentication between said devic- 
es in response to said detected proximity; and 
engaging said devices in secure wireless com- 
munication following said authentication. 

35 

2. The method of claim 1 , wherein detecting the phys- 
feal proximity of said devices comprises perfomiing 
a hardware handshake via an interface having a 
limited operating range. 

40 

3. The method of claim 2, wherein said limited operat- 
ing range interface requires physical contact be- 
tween said two devices. 

45 4. The method of claim 3, wherein said physical con- 
tact comprises contact selected from the group con- 
sisting of electrical contact between at least one 
electrode disposed on the exterior of each said de- 
vice, electrical contact between said devices via at 
50 least one electrically conductive cable connected 
between said devices, and optical contact between 
said devices via at least one optically conductive 
waveguide connected between said devices. 

S5 5. The method of claim 2, wherein said limited operat- 
ing range Interface Is selected from the group con- 
sisting of electro-magnetic coupling, inductive cou- 
pling, backscatter modulation of a radio frequency 
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electro-magnetic field, magnetic coupling, capaci- 
tlve coupling, sonic signals transferred between 
said devices, and llne-of-sight transmission of opti- 
cal signals between said devices. 

6. The method of claim 1 , wherein said physical prox- 
imity of said devices is in the range from 0 to about 
6 Inches. 

7. The method of claim 6, wherein said physical prox* 
imity of said devices is In the range from 0 to about 
2 inches. 

8. The method of claim 7. wherein said physical prox- 
imity of said devices comprises physical contact be- 
tween said devices. 

9. The method of claim 2, wherein perfonning a hard- 
ware handshake occurs only when at least one of 
said devices is in a hardware handshake mode. 

1 0. The method of claim 9, additionally comprising plac- 
ing said device in said hardware handshake mode 
by an action selected from the group consisting of 
actuation of a switch, entering a password, and 

completing a biometric scan. 

1 1 . The method of claim 1 , wherein performing authen- 
tication between said two devices in response to 
said detected proximity comprises transfening a se- 
curity code from one said device to the other. 

12. The method of claim 11 , wherein said security code 
is transferred across said wireless communications 
link. 

13. A method of selectively allowing authentication be- 
tween a first and second device, each said device 
capable of wireless communications, said first de- 
vice having a first mode wherein said authentication 
Is Inhibited and a second mode wherein said au- 
thentication Is allowed, comprising: 

operating said first device In said first mode; 
entering said second mode in response to de- 
tecting the physical proximity of said second 
device by said first device; and 
perfonning said authentication in said second 
mode. 

14. The method of claim 13, wherein detecting the 
physical proximity of said second device by said first 
device comprises the completion of a hardware 
handshake between said first and second devices, 
said handshake occurring across an Interface with 
a limited operating range. 

15. The method of claim 14, wherein said hardware 



handshake is perfomned only when said first device 
Is in a handshake mode. 

16. The method of claim 15, additionally comprising 
5 placing said device in said hardware handshake 
mode by an action selected from the group consist- 
ing of actuation of a switch, entering a password, 
and completing a biometric scan. 

10 17. The method of claim 13, wherein perfomning said 
authentication In said second mode includes trans- 
fening a security code from said first device to said 
second device. 

IS 1 8. The method of claim 1 7, wherein said security code 
is transferred across said limited operating range 
interface. 

19. The method of claim 17, wherein said security code 
20 ts transferred across the wireless communtoations 

Interface of said first and second devtees. 

20. A first device capable of wireless communications, 
adapted to detect the physical proximity of said first 

25 device to a second device capable of wireless com- 
munications, and further adapted to allow authenti- 
cation with said second device thereby enabling se- 
cure wireless communications therebetween. In re- 
sponse to said detection of physical proximity of 

30 said first and second devices. 
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